(レポート)BDT322: RedfinとTwitterはいかにしてS3をつかってビッグデータプラットフォームを構築しているのか #reinvent

AWSのビッグデータ関連サービスと言えばAmazon Redshift、Amazon EMR、Amazon Kinesisなどが思い浮かびますが、ビッグデータのストア先として欠かせないのがAmazon S3です。

本セッションでは、RedfinとTwitterの、ビッグデータ分析基盤でのS3活用事例が紹介されています。

イントロダクション

セッションは、AWSのPrincipal Solution ArchitectのIan Meyers氏による、S3についての紹介から始まります。

S3の紹介

• オブジェクトサイズ : 最大5TBまで格納できる
• 99.999999999%の耐久性、99.99%の可用性
• SPOFが無い
• サーバーサイドの暗号化をサポート
• アクセス頻度に応じてcost-effectiveなオプションを選択できる : Standard/Infrequent Access/Glacier
• イベント連携 : Lambda、SQS、SNS

S3のユースケース

ビッグデータプラットフォームでの、S3の典型的なユースケースについての紹介されていました。

• プライマリのデータストア
• DynamoDB、Redshift、Lambda、ERM、Datapipeline、Kinesis、Machine Learning等のサービスと連携
• HDFSの代替(EMRFS) (S3でデータを永続化し、HDFSはジョブ実行時のテンポラリーストレージとして使う)
• ERMのクラスターをシャットダウンできる
• HDFSのスケーリングについて考慮が不要となる
• データを複数のERMのクラスターでシェアできる
• HadoopとHDFSのバックアップ
• HBaseのIncremental Backup
• データ中心のEvent Bus
• EC2からS3をs3fs等を使ってマウントし、SFTPで受けたデータを直接S3へ保存
• イベント連携でLambdaを起動し、データをRedshiftへ投入

RedfinでのS3の活用事例

Youg Huang氏による、RedfinでのS3活用事例の紹介です。

• Redfinはエージェントがユーザーの不動産売買をサポート、エージェントにはユーザーの満足度に応じてボーナスを支払う
• 毎月数百万のユーザーによる数十億のイベントが発生
• 数千のエージェント、80のマーケット
• エージェントが集めた不動産に関する情報、ユーザーの情報を分析

データ分析基盤の概要

• バッチプロセス
• 生データはS3に保存
• データはERMで処理し(処理結果はS3に保存)、RedshiftやDynamoDBに格納
• ERMのクラスターはEC2のスポットインスタンスを使用。データの処理が終わったらクラスターをシャットダウンしコストを削減
• バッチ処理は複数の独立したタスクで構成。タスク単位で再実行が可能
• 処理のチェックポイント毎にデータをS3に保存

• リアルタイムプロセス

• ストリームデータの処理にはSQS、Kinesisを使用

ストレージサービスの使い方

• ERM : テンポラリーデータ
• SQL/Kinesis : イベントバス、ストリーミングデータ
• S3 : プライマリデータストア、データの永続化
• DynamoDB : データキャッシュ
• Redshift : DWH

• すべてのデータはS3に保存

• ROWデータ、ステージングデータ、プロダクションデータ

• データはS3から再取得可能、再処理可能

• S3を採用する理由

• シンプルで使い易い
• スケーラブル
• 高い耐久性
• AWSサービスとの親和性

Twitter

続いてTwitterのJoseph Unruh氏による、同社のTellApart部門でのS3の活用事例の紹介です。

TellApartは、ディスプレイ広告、パーソナライズした広告メッセージをリアルタイムで挿入するマーケティング技術を提供していた企業で、今年の4月にTwitterが買収しました。

• 秒間20万リクエスト/秒、毎日15〜20TBのデータをS3に保存
• ユーザーに有意義な広告を届けるためには？
• 100ms以内にユーザーを特定、購買履歴、プロファイルの情報、広告への入札額を確認

ラムダアーキテクチャ

• バッチレイヤ
• バックエンドでユーザーグラフ等を作成し、Read-OnlyのDBへデータを投入
• スピードレイヤー
• KafkaとSpark
• 最新の履歴データなどをSpeedDB(Redisベース)に格納
• これらをFrontendでマージ
• Redfinのようにバッチ処理はスポットインスタンスを利用。(Spot Fleetに移行中)

S3のユースケース

Hadoop、Sparkのデータストアの他、Apache Aurora用のDockerコンテナストレージとしてもS3を活用しているとのこと。

キャッシュレイヤー

• S3では速度的に要件を満たさない場合があるため、キャッシュレイヤーを用意
• ２週間前までのデータはHDFSに、直近のデータはTACHYONに保存

S3のパフォーマンス関連のTIPS

• ロード分散
• EC2の帯域幅の制限を考慮する
• r3.8xlarge × 1台より、r3.2xlarge × 4台の方がS3からのデータ転送が早い
• ただし、台数が増えるとEC2間のデータ転送がボトルネックとなるため、限界はある
• Reading/Writing
• マルチパートアップロード/ダウンロードを使う
• SPARKを使うときは、JetS3tではなく新しいs3aライブラリを使う(後者の方がより高パフォーマンスでエラーリカバリに優れている)
• list処理を避ける
• Map/Reduce
• 投機的実行を無効化する
• ファイルサイズをHDFSのブロックサイズと同じまたは若干小さめ(SparkとHadoopはブロックサイズに基づきデータを分散するため)
• カラムベースのファイルフォーマットを使用する(Parquetなど)

まとめ

バッチ処理を「S3 + スポットインスタンス」の組み合わせで実行することでコストを削減している点がRedfin、Twitter共通のプラクティスでした。S3でビッグデータを扱う上でのTIPSもとても参考になりました。

極めて高い耐久性に加え、データのImport/Export、イベント連携など、他AWSサービスとの連携機能がサービスレベルで備わっているのがS3の特徴です。この特徴を活かし、ビッグデータの文脈に限らず、S3を中心にデータフローを設計するのがAWSでのベストプラクティスと言えるかと思います。